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Description 

Background of the Invention 

Field of the Invention 

The present invention relates to the support of on- 
demand pause-resume in a central video server. 

Related Art 

The feature of pa use -resume is one of the most 
common operations in VCR. Recently, it has become 
increasingly popular to develop multimedia servers to 
support video-on-demand (VOD) applications. In a VOD 
environment there are often hot videos which are re- 
quested by many viewers. The requirement that each 
viewer can independently pause the video at any in- 
stance and later resume the viewing has caused diffi- 
culties in batching of viewers on each showing. 

In one conventional approach to support on-de- 
mand pause-resume, one video stream is provided for 
each viewer video request. For each multimedia server, 
there is a maximum number of video streams to the 
disks that can be supported. This upper limit will be re- 
ferred to as N MAX . Thus, the above-described approach 
can only support N MAX viewers. 

In another conventional approach to the pause- 
resume problem, video streams for "hot" (popular) mov- 
ies are scheduled such that they commence at fairly 
close intervals. In response to receipt of a resume com- 
mend from a viewer (after having received a pause) the 
server assigns to the viewer one of the video streams 
for the same movie which is scheduled to reach the 
proper resume point in the near future. One problem 
with such a system is that the viewer must wait until a 
stream reaches the proper resume point before the 
movie can be viewed from the point at which the viewer 
paused. 

Communications- Rising to the heights, Denver, 
23.06.91, vol. 2 of 3, IEEE, pages 842-846, XP 000 269 
608, discloses a store-and-forward architecture for VOD 
supporting a pause function. 

Summary Of The Invention 

It is an object of the invention is to support pause 
and quick resume for a larger number of viewers than 
n max- 

In accordance with an embodiment of the present 
invention there is provided a system and method of sup- 
porting pause-resume in a video-on-demand service of 
a type which can accommodate multiple viewers shar- 
ing a common data stream. When a video server re- 
ceives a performance request from one of the viewers 
for showing a particular video, it identifies and reserves 
a look-ahead stream. The look-ahead stream is another 
video stream which is scheduled to become available 



after a predetermined time period. When the video is 
commenced, a common data stream for the video is 
concurrently transmitted from the video server to recep- 
tion equipment at the viewers' locations. Transmission 

5 of the common data stream causes the particular video 
to be performed on the viewers' reception equipment. 
When the video server receives a pause request and 
then a subsequent resume request from one of the view- 
ers, it transmits the video via the look ahead stream in- 
to stead of the common data stream. 

In a preferred embodiment, "look-ahead" stream 
scheduling with "look-aside 1 ' buffering is used to support 
a larger number of viewers than N MAX , This system 
avoids the need for backing each viewer by a real video 

15 stream capacity from the disk. 

If a buffer to store t time units of showing is availa- 
ble, two viewers share the same video stream as long 
as another stream will become available within t time 
units. This eliminates the need for a real stream capacity 

20 at least for t units of time. Look-ahead scheduling backs 
up viewers with a future (look-ahead) stream which is 
currently being used for another showing so he can 
pause and resume at any time. Before the look-ahead 
stream becomes available, the pausing and resuming 

25 viewing are supported by the original stream through 
buffering of the missed content. If there is not enough 
buffer space to support look-ahead scheduling, a re- 
served stream is used. 

A reserved stream is an otherwise unused stream 

30 capacity of the server. When a reserved stream is allo- 
cated, the useable stream capacity of the multimedia 
system is reduced by one. With a reserved stream, a 
viewer who is sharing a common video stream with other 
viewers can pause at any time. When the viewer 

35 resumes, the reserved stream becomes the viewers ac- 
tive stream to be viewed. 

At the time when the video showing associated with 
a look-ahead stream completes, if another playing or re- 
served stream can be found which will be completed 

^0 within t units of time, a new look-ahead stream can be 
designated and the completing look-ahead stream can 
be used to schedule other viewers. So a viewer may be 
supported by a sequence of different look-ahead 
streams during the showing. 

45 Thus each viewer is supported by either the real 
stream showing the video, some look-ahead stream, or 
a reserved stream. Each real stream or reserved stream 
for a given showing can support one look-ahead stream 
of another showing. There is an additional level of com- 

50 plexity due to the fact that the viewer of a look-ahead 
stream may pause so that the actual finishing time can 
be uncertain. To get around this problem, a stream, once 
chosen as a look-ahead stream, is not allowed to pause. 
Instead, when the viewer pauses, the stream is buff- 

55 ered. Then, when the viewer resumes he views the vid- 
eo from the buffer. Once a viewer can get the remaining 
portion of the video from the buffer, there will be no fur- 
ther stream requirement for the video. The viewer's buff- 
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er contents are not released until the viewing is com- 
pleted. 

Brief Description of the Drawings 

5 

Fig. 1 is a block diagram of a multi-media server; 

Fig. 2 is a block diagram of the (look-aside) buffer 
status; 

10 

Fig. 3 shows the stream status table; 



stream switching process. 

Like reference numerals appearing in more than 
one drawing depict like elements. 

40 

Detailed Description Of A Preferred Embodiment 

FIG. 1 is a block diagram of a video-on-demand sys- 
tem according to an embodiment of the present inven- 
tion. In the following description, it is assumed that in a *s 
video-on-demand system clients t make requests from 
a video server 2 via a communication network 3. The 
movies (videos) are stored on disks 5. The server 2 in- 
cludes memory buffers 6 for temporary storage of mov- 
ies for handling short pause requests. The video server 50 
2 also includes a processor 7 (cpu) which executes 
tasks under control of a main control program (mcp) 8. 
The video server can be embodied using any processor 
of sufficient performance for the number of video 
streams to be supported. For example, a small capacity 55 
VideoServer could be embodied using an RISC System/ 
6000 (RS/6000) system while a larger capacity server 
could be embodied using an ES/9000 system (both 



available from International Business Machines Corpo- 
ration of Armonk, New York). The communication net- 
work 3 can be, for example, a fiber optic network. The 
clients 1 are supported by a set-top box which enables 
them to send commands to the server 2 by way of the 
network 3. 

In accordance with an embodiment of the present 
invention, one of the tasks is a look-ahead scheduler 9. 
The clients can make requests to start, stop, pause and 
resume a movie. The individual client requests are han- 
dled by a client scheduler 40. The look-ahead scheduler 
9 attempts to conserve server resources by combining 
requests for the same movie that are close together in 
time while allowing each client to individually pause and 
resume. 

The look-ahead scheduler 9 maintains a buffer sta- 
tus table 4 which tracks the use of the memory buffer 6. 
Referring now to Fig. 2, the (look-aside) memory buffer 
status will be described. Each buffer block can be in one 
of the three states: reserved, in-use, and available. As 
will be explained in detail later, during scheduling of vid- 
eos, buffers can be put into a "reserved" state to support 
pause-resume. A "reserved" buffer changes to an "ac- 
tive" (in-use) state when a video stream is stored into it. 
The buffers which are neither "reserved" nor "active" are 
available for future allocation. 

The look ahead scheduler also maintains a stream 
status table 1 1 which will now be described by reference 
to Fig. 3. The multimedia server can only support a fixed 
number of streams. A stream is considered to be "ac- 
tive", if it is supporting an actual showing of a video. A 
stream is considered "reserved" if it is reserved to sup- 
port pause-resume of concurrent viewers of a showing. 
If a stream capacity is neither "active" nor "reserved", it 
is available for future showing. 

Fig. 3 illustrates one way to do the bookkeeping. 
For each stream, the status of active, reserved or none 
is recorded. The absence of a recorded status (none) in 
both the active field 301 and reserved field 302 indicates 
that the stream is available. For a reserved stream, in- 
formation on the corresponding active stream showing 
the video is also recorded in the "reserved" field 302. If 
a stream is designated as a look-ahead stream for a 
viewer in another showing being serviced by an active 
stream, information identifying that active stream is pro- 
vided in the "look-ahead" field 304. The ID of the video 
showing on the active stream is recorded in a video ID 
field 306. 

For example, in Fig. 4, assume that three video re- 
quests for video A get scheduled at time ^ and at that 
moment, there is no other active stream. Stream 1 is 
chosen as the active stream and streams 2 and 3 are 
designated as reserved streams for concurrent viewers 
on stream 1 . (See the reserved field of streams 2 and 3 
in Fig. 3.) At time ^ two video requests for video B get 
scheduled. Assume that stream 1 is within t units of time 
to completion and there is sufficient buffer to support 
stream 1 as a look-ahead stream. We can choose 



Fig. 4 shows a time line for a video request process- 
ing example; 

15 

Fig.' 5 is a flow diagram of an overall view of the 
look-ahead scheduler of FIG. 1 , according to an em- 
bodiment of the present invention. 

Figs. 6a & 6b are a more detailed diagram of the 20 
look ahead scheduler task; 

Fig. 7 is a more detailed flow diagram of the pause 
operation; 

25 

Fig. 8 is a more detailed flow diagram of the resume 
operation; 

Fig. 9 is a more detailed flow diagram of the stream 
completion operation; 30 

Fig. 1 0 is a more detailed flow diagram of the view- 
ing completion operation; 

Fig. 1 1 is a more detailed flow diagram of the ahead 35 
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stream 4 as the active stream and use stream 1 as the 
look-ahead stream. (See Fig 3 on the look-ahead field 
of stream 1 .) Note that this second group of viewers (of 
video B) are not current viewers of stream 1 . They mere- 
ly use stream 1 (which is currently carrying video A) as 5 
a look-ahead stream to support pause-resume opera- 
tions. Hence, viewers of stream 1 always means the first 
group of viewers which is currently viewing video A. If 
another four requests for video C are scheduled imme- 
diately afterwards, stream 5 can be used as the active 10 
stream and streams 2 and 3 as the look-ahead steams, 
assuming sufficient buffer. In addition, stream 6 is need- 
ed as a reserved stream. (See the look-ahead field of 
streams 2 and 3 and the reserved field of stream 6 in 
Fig. 3.) Figure 3 shows the stream status at this point, is 
where there are 9 viewers consuming six stream capac- 
ities. 

Assume that the multi-media system has a buffer 
for look-aside purposes of size B and a stream capacity 
°* N MAX - t- et Nresrv De tne number of reserved streams 20 
in the system and N ACT be the number of active streams 
showing the videos. Let B RESRV be the amount of look- 
aside buffer reserved and B USE be the amount of look- 
aside buffer currently in use. We further assume that 
each unit of time showing requires K bits of data. 25 

Each time a video is selected for showing if N w cus- 
tomers are waiting for that video, the following proce- 
dure determines the largest number of viewers, C, that 
can be scheduled to allow for pause-resume. The pro- 
cedure uses as many look-ahead streams as possible 30 
given the buffer constraint, and support the remaining 
viewers by reserved streams. To be more specific, 

1. First the maximum number of additional look- 
ahead streams supportable given the current buffer 35 
usage is determined. This is referred to as N^^q 
and is the minimum of the following two quantities, 

The number of video streams (not yet marked 
as look-ahead streams) to be completed in the 40 
next t units of time assuming no pausing, where 
t is a pre-specified operating parameter deter- 
mined from the amount of buffer space availa- 
ble to support pause-resume. These are the po- 
tential look-ahead streams. 45 

The number of additional look-ahead streams 
supportable by the current state of the buffer. 
Let us order the potential look-ahead streams 
based on their remaining time to completion, so 
assuming no pausing. From a buffering view 
point, one would choose look-ahead streams 
on that order, i.e. choose look-ahead streams 
based on their completion times. Assuming that 
the \th potential look-ahead stream has a re- 55 
maining time to completion of tctj, it will need a 
buffer of size tKa } to be reserved if chosen. This 
buffer amount is needed to save the video con- 



tents to completion if the current viewer of the 
potential look-ahead stream goes into a pause 
mode. (It is large enough to stream the rest of 
the showing into buffer, even in the worst case 
of immediate pausing.) If x look-ahead streams 
are chosen, an amount of xtKa additional re- 
served buffer will be needed to handle pausing 
of their associated viewers, where at is the av- 
erage remaining time to complete for the first x 
potential look-ahead streams, i.e: 



oc= c^) fx 

2-1 



In addition, an amount of tK buffer space 
needs to be reserved to support short pausing 
of the new group of viewers (currently waiting 
to be scheduled) before the look-ahead 
streams become available. Hence, with x look- 
ahead streams chosen, the total amount of 
buffer needs to be reserved is (tK + xtKa). 
Thus, from the buffer view point the maximum 
supportable look ahead streams is the largest 
x value such that the buffer constraint is satis- 
fied. 

2. If this maximum number (x) is larger than N w -1 , 
all of these requesting viewers can be scheduled 
with one real stream for showing the video, and N w - 
1 look-ahead streams. In this case, C equals to N W - 

3. Otherwise, the number of look-ahead streams 
used is N^h^q. We need to obtain some streams 
capacities to put in reserved mode in order to 
schedule additional viewers not backed up by the 
look-ahead streams. The reserved streams obtain- 
able must be smaller than the number of streams 
available, N AVAIL , which is equal to N MAX - (N RESRV 
+ Nact)- If N w - N^h^q - 1 streams or more are 
available to be put into reserved mode, all request- 
ed viewers can still be scheduled, i.e. C equals to 
N w . Otherwise, C will be N AVAIL + N^^. 

Let D be the number of look-ahead streams used. 
We will then set B RESRV equal to tK + DKa + B RESRV 
and increase N ACT by one. Also if reserved streams are 
used, N RESRV is increased accordingly. Note that B USE 
will be incremented when the reserved buffers are ac- 
tually in use to support the pause action. (B RESRV will 
be decremented for the same amount.) This buffer will 
be released when not needed. 

The buffer constraint in step 1 , can be expressed 
as 0(tK + xtKa + B RESRV ) < (B - B USE ), where 0 (theta) 
is a tuning parameter. Setting 0 equals to one guaran- 
tees that the paused viewer will always be able to get 
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back with no delay. In reality, not all viewers are going 
to pause at the same time, so 0 can be set at a lower 
value while still maintaining very low probability that the 
returned viewer would need to watt. Similarly, N AVAjL can 
be redefined to be N MAX - (0'N RESRV + N ACX ), where 0' 
is another tuning parameter Note that in the case of a 
guaranteed no-delay resume, 0' is set to one. 

The look-ahead streams assigned can be delayed. 
For an additional 0tK amount of buffer that can be re- 
served within the next t units of time, look-ahead 
streams can be allowed to be available t time units later. 
This rule can be applied repeatedly. 

When a stream which is designated as a look- 
ahead stream is completed, if another look-ahead 
stream can be found to replace it (i.e. within t units of 
time to completion), new viewer requests can be sched- 
uled using the newly available stream capacity. Other- 
wise it becomes a reserved stream. If a look-ahead 
stream will become available after t+w units of time, the 
reserved stream can be replaced by that look-ahead 
stream after w units of time. It can then be scheduled 
for other viewing. 

Another optimization to improve the throughput is 
to allow a resuming stream to merge with a later-show- 
ing real stream. Still an appropriate look-ahead stream 
is required as before to support additional pausing in the 
future. 

Referring now to FIG. 5 there is shown a flow dia- 
gram of an overall view of a scheduling method accord- 
ing to an embodiment of the present invention. The vid- 
eo request arrival is indicated in step 10. In step 15, the 
available stream capacity is checked. If there is no avail- 
able stream capacity, step 20 is executed where the in- 
coming video request is put into a request wait queue. 
Otherwise, if there is available stream capacity, steps 
25-40 are executed. In step 25, the video request or re- 
quests is scheduled. The details of the scheduling pro- 
cedure are given in Fig. 3. Once a video is scheduled, 
each viewer can pause and then resume at any time 
desired as indicated in step 30 for pausing operation and 
step 35 for resuming. The details of the bookkeeping to 
support the pause and resume operations are given in 
Figs. 4 and 5, respectively. Step 40 represents the com- 
pletion of the viewing by a requester. The details of the 
operation associated with the viewing completion are 
given in Fig. 6. 

Referring now to Figs. 6a and 6b the details of the 
scheduling operation are shown in more detail. In step 
50, it is assumed that each time a movie is selected for 
showing., there are N w customers waiting for that movie. 
In step 55, the number of available streams that may be 
marked as look-ahead streams is determined. This is 
the number of streams, not yet marked as look-ahead 
streams, that can be completed in the next t units of time 
assuming no pausing requests. In step 60, the maxi- 
mum number of look-ahead streams (N^h^q) support- 
able for the given buffer size is determined. 

In step 65, N^^n is compared to N^, . If N WHEAD 



is larger than N w _., , all requesters can share one video 
stream, where another N w look-ahead streams are 
used to backup the pausing requirement, as indicated 
in step 70. In step 75, the number of buffer required to 
s support the look-ahead scheduling is put into reserve 
mode. 

Going back to step 65, if the maximum number of 
look-ahead streams supportable for the given buffer 
size is smaller than r\l w ..,, there are not enough look- 
ahead streams, hence some video stream capacity 
needs to be put into reserve mode. Step 80 determines 
the number of video streams that are currently available 
(i.e. neither showing nor reserved). In step 85, the 
number of available video streams is compared to the 
requirement to support outstanding viewers for the vid- 
eo. If there is enough available video streams, steps 90 
and 95 are executed. Otherwise, steps 1 00 and 1 05 are 
executed. In steps 90 and 100, the appropriate number 
of requesters are scheduled for viewing the video show- 
ing, respectively. In steps 95 and 105, the appropriate 
number of video streams are put into reserved mode, 
respectively. In step 110, the amount of buffer space re- 
quired to support the look-ahead scheduling is put into 
reserve mode. In steps 115 and 120, the bookkeeping 
on the scheduling is complete. 

Referring now to Fig. 7 the details of the pausing 
operation are shown in more detail. Step 1 30 indicates 
the arrival of a pause request at the video server. In step 
1 35, it is checked whether that viewer can be supported 
by a look-ahead stream. If the viewer can be supported 
by a look-ahead stream, as indicated by step 140, the 
reserved buffer is put into use to temporarily buffer the 
missing contents for the pausing viewer up to t units of 
time. In step 145, the pausing period is checked. If it 
exceeds the limit, in step 150 the buffer is released if no 
other viewers are using it. 

If, in step 135, the viewer can not be supported by 
a look-ahead stream, in step 155 it is further checked if 
the supporting stream is marked as a look-ahead stream 
for another viewer. If this is true, in step 160, the video 
stream will continue streaming the video into the buffer 
until completion. The stream completion operation indi- 
cated in step 170 is explained in Fig. 9. In step 155, if 
the stream is not marked as look ahead, it can be 
stopped as indicated in step 1 75. 

Referring now to Fig. 8 we examine the details of 
the resume operation. In step 200, it is checked whether 
the resuming point is available in the buffer. If so, as in- 
dicated in step 205, the viewer resumes the viewing 
from the buffer. Otherwise, as indicated in step 210, a 
reserved stream will be made into an actual showing 
stream to support the resumed viewer. 

Referring now to Fig. 9 the details of the stream 
completion operation are shown. In step 220, when a 
video stream is completed, the scheduler determines 
whether this stream or any other associated reserved 
stream has been marked as a look-ahead stream. For 
each stream marked as a look-ahead stream, as indi- 
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cated in step 230, the scheduler determines whether an- 
other stream can be identified and switched into a look- 
ahead stream. This is addressed in details in Fig. 8. If 
another stream can be switched to a look-ahead stream, 
steps 235 and 240 are executed. In step 235, that 
stream is designated as a new look-ahead stream to re- 
place the completing video stream and in step 240, the 
completing stream is released as an available stream 
and the process of scheduling new video requests can 
be initiated if there are waiting video requests, (the 
stream scheduling process is described in Fig. 6.) In 
step 230, if no other stream can be switched into a look- 
ahead stream, steps 245 and 250 are executed. In step 
245, the completing stream is made into a reserved 
stream, and in step 250, the appropriate bookkeeping 
is done. 

Referring now to Fig. 10 we examine the details of 
the viewing completion operation. Note that viewing 
completion can be later than the stream completion, 
since during pausing, the video stream may continue 
and be saved in the buffer. In step 280, all buffer space 
in use or reserved for the completing viewer is released 
if not needed by another viewer. In step 285, simultane- 
ous stream completion is checked. If so, the appropriate 
actions depicted in Fig. 6 are performed. 

Finally referring now to Fig. 11 the details of the 
process of switching look-ahead stream will be de- 
scribed. Fig. 8 is a more detailed flow diagram of step 
230 of Fig. 6. In step 300, let e (epsilon) be the lag of 
the look-ahead stream to the actual showing stream. In 
step 305, the value of epsilon is examined. If it is not 
equal to zero, in step 31 0, the amount of available buffer 
is examined. If there is sufficient buffer (larger than B MIN ) 
after some additional allocation (of the amount of Stke), 
steps 31 5 and 320 are executed. In step 31 5, that addi- 
tional buffer allocation is being made, and in step 320, 
the look ahead interval is set to t. In step 335, it is 
checked for whether any stream not yet marked as a 
look-ahead stream can terminate in the next t time units, 
assuming pausing does not occur. (If so, in step 235, 
the earliest terminating stream assuming no pausing is 
chosen as the look-ahead stream to switch over.) 

Returning to step 310, if there is insufficient buffer 
(not larger than B MlN ) after some additional allocation 
(of the amount of 0tke), no additional buffer is reserved 
and steps 325 and 335 are executed. In step 325, the 
look ahead interval is set to t - e. 

Returning to step 305, if the value of e is equal to 
zero, steps 330 and 335 are executed. In step 330, the 
look ahead interval is set to t. 

Now that the invention has been described by way 
of the preferred embodiment, various modifications and 
improvements will occur to those of skill in the art. Thus, 
it should be understood that the preferred embodiment 
has been provided as an example and not as a limita- 
tion. The scope of the invention is defined by the ap- 
pended claims. 



Claims 

1 . A method of supporting pause-resume for a video- 
on-demand system of a type which can accommo- 
date multiple viewers sharing a common data 
stream, comprising the steps of: 

receiving a performance request from one of 
the viewers for showing a particular video; 

in response to the performance request, iden- 
tifying and reserving a look-ahead stream, the 
look ahead stream being another video stream 
which is scheduled to become available after a 
predetermined time period; 

concurrently transmitting the common data 
stream from a video server to reception equip- 
ment at the multiple viewers' locations, trans- 
mission of the data stream causing the partic- 
ular video to be performed on the reception 
equipment; 

receiving at the video server, a pause request 
and a subsequent resume request from one of 
the viewers; and, 

in response to the resume request, transmitting 
the particular video by way of the look ahead 
stream instead of the common data stream. 

2. The method of Claim 1 wherein 

a different look ahead stream is identified after 
a period of time has elapsed without the viewer 
initiating a pause request. 

3. The method of claim 1 or 2 wherein 

in response to the performance request the one 
of the viewers is assigned a reserved stream 
which is released when the look ahead stream 
is identified. 



45 4. The method of one of claims 1 to 3 wherein 

the one of the viewers is allocated sufficient 
buffer space to buffer the common video 
stream for a predetermined period of time. 



10 



1S 



20 



25 



30 



35 



40 



SO 



55 



5. The method of one of claims 1 to 4 comprising the 
further step of 

buffering video data streams in response to 
pause requests from the viewers : whereby a 
number of viewers supportable by a given 
stream capacity is increased. 
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6. A system for supporting pause-resume for a video- 
on-demand system of a type which can accommo- 
date multiple viewers sharing a common data 
stream, comprising: 

5 

receiving means for receiving a performance 
request from one of the viewers for showing a 
particular video; 

identifying means, coupled to the receiving 10 
means and responsive to receipt of the per- 
formance request, for identifying and allocating 
a look-ahead stream, the look ahead stream 
being another video stream which is scheduled 
to become available after a predetermined time is 
period; 

transmission means for concurrently transmit- 
ting the common data stream from a video serv- 
er to reception equipment at the multiple view- 20 
ers locations, transmission of the data stream 
causing the particular video to be performed on 
the reception equipment; 

pause/resume means for receiving a pause re- 25 
quest and a subsequent resume request from 
one of the viewers; and, 



quest is received within the predetermined pe- 
riod of time. 

10. A method of supporting pause-resume for a video- 
on-demand service of a type which can accommo- 
date multiple viewers sharing a common data 
stream, comprising the steps of: 

receiving a performance request from one of 
the viewers for showing a particular video; 

concurrently transmitting the common data 
stream from a video server to reception equip- 
ment at the multiple viewers' locations, trans- 
mission of the data stream causing the partic- 
ular video to be. performed on the reception 
equipment; 

receiving at the video server, a pause request 
and a subsequent resume request from one of 
the viewers; 

in response to the resume request, performing 
the particular video for the one of the viewers 
by commencing transmission of an alternative 
stream carrying the particular video other than 
the common data stream. 



substitution means, for in response to the 
resume request, transmitting the particular vid- 
eo by way of the look ahead stream instead of 
the common data stream. 

7. The system of Claim 6 wherein 

a different look ahead stream is identified after 
a period of time has elapsed without the viewer 
initiating a pause request. 

8. The system of claim 6 or 7 wherein 

the viewer is assigned a reserved stream which 
is released when the look ahead stream is iden- 
tified. 

9. The system of one of claims 6 to 8 wherein 

the substitution means does not transmit the partic- 
ular video by way of the look ahead stream unless 
the resume request is received in greater than a 
predetermined period of time from the pause re- 
quest, and further comprising: 



30 



35 



40 



45 



50 



11. The method of claim 10 wherein 

the particular video is commenced at a point 
from which the one of the viewers made the 
pause request. 

12. The method of claim 10 or 11 comprising the further 
step of: 

buffering video data streams in response to 
pause requests from the viewers, whereby a 
number of viewers supportable by a given 
stream capacity is increased. 

13. The method of one of claims 10 to 12 comprising 
the further steps of: 

in response to the performance request, iden- 
tifying and allocating a look-ahead stream, the 
look ahead stream being another video stream 
which is scheduled to become available after a 
predetermined time period; and, using the look- 
ahead stream as the alternative stream. 



buffer means for, in response to the pause re- 
quest, buffering the common video stream for 
the predetermined period of time, and 

buffer access means, for serving the one of the 
viewers from the buffer means if the resume re- 



14. The method of one of claims 10 to 13 wherein 

55 the alternative is a reserved stream allocated 

from reserve capacity of the video server 

15. The method of one of claims 10 to 14 comprising 
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the further steps of: 

assigning buffer space to buffer the common 
video stream for a predetermined period of 
time, and 

when the one of the viewers resumes before 
the predetermined period of time, serving the 
one of the viewers the particular video from the 
buffer space instead of by way of the alternative 
stream. 



Patentanspruche 

1. Ein Verfahren zur Unterstutzung einer Pause-und- 
Wiederaufnahme-Anforderung in einem Video-auf- 
Anforderung-System eines Typs, der eine Vielzahl 
Zuschauer sich gleichzeitig in einen gemeinsamen 
Datenstrom teilen lafBt, das aus den folgenden 
Schritten besteht: 

Empfangen einer Vorfuhranforderung von ei- 
nem der Zuschauer zum Vorfuhren eines be- 
stimmten Videos; 

als Reaktion auf die Vorfuhranforderung Iden- 
tifizieren und Reservieren eines Vorgriffs- 
stroms, wobei dieser Vorgriffsstrom ein anderer 
Videostrom ist, der so geplant ist, daB er nach 
einer vorgegebenen Zeitspanne verfugbar ist; 

gleichzeitiges Ubertragen des gemeinsamen 
Datenstrom vom Video-Server auf die Emp- 
fangsgerate an den Orten der Vielzahl von Zu- 
schauern, wobei die Ubertragung des Daten- 
stroms bewirkt, daB das bestimmte Video auf 
dem Empfangsgerat der Zuschauer vorgefuhrt 
wird; 

Eingang einer Pauseanforderung und einer 
nachfolgenden Wiederaufnahmeanforderung 
von einem der Zuschauer beim Video-Server; 
und 

als Reaktion auf die Wiederaufnahmeanforde- 
rung das Ubertragen des betreffenden Videos 
uber einen Vorgriffsstrom anstatt uber den ge- 
meinsamen Datenstrom. 

2. Das Verfahren gemaB Anspruch 1 , in dem 

nach Verstreichen einer bestimmten Zeitspan- 
ne, ohne daB der Zuschauer eine Pausenan- 
forderung eingeleitet hat, ein anderer Vorgriffs- 
strom identifiziert wird. 

3. Das Verfahren gemaB Anspruch 1 oder 2, in dem 
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15 



25 
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als Reaktion auf die Abspielanforderung dem 
einen der Zuschauer ein reservierter Strom zu- 
geteilt wird, der wieder freigegeben wird, wenn 
der Vorgriffsstrom identifiziert ist. 

Das Verfahren gemaB einem der Anspruche 1 bis 

3, in dem 

dem einen der Zuschauer genugend Puffer- 
raum zugeteilt wird, um den gemeinsamen Vi- 
deostrom fur eine vorgegebene Zeitspanne zu 
puffern. 

Das Verfahren gemaB einem der Anspruche 1 bis 

4, das ferner die folgenden Schritte enthalt: 

Puffern der Videodatenstrome als Reaktion auf 
Pausenanforderungen seitens der Zuschauer, 
wobei die Anzahl der Zuschauer, die von einer 
gegebenen Stromkapazitat versorgt werden 
konnen, erhoht wird. 

Ein System zum Unterstutzen einer Pause-Wieder- 
aufnahme-Anforderung fur ein vldeo-auf-Abruf-Sy- 
stem eines Typs, der eine Vielzahl Zuschauer sich 
gleichzeitig in einen gemeinsamen Datenstrom tei- 
len laBt, wobei dieses System umfaBt: 

Empfangsmittel zum Empfangen einer Vorfuh- 
rungsanforderung seiten eines der Zuschauer 
auf Vorfuhren eines bestimmten Videos; 

Identifizierungsmittel, gekoppelt an die Emp- 
fangsmittel, die auf den Eingang der Vorfuh- 
rungsanforderung mit Identifizieren und Zutei- 
len eines Vorgriffsstroms ansprechen, wobei 
der Vorgriffsstrom ein anderer Videostrom ist, 
der planungsgemaB nach Ablauf einer be- 
stimmten Zeitspanne verfugbar wird; 

Ubertragungsmittel zum gleichzeitigen Uber- 
tragen des gemeinsamen Datenstroms von ei- 
nem Video-Server zum Empfangsgerat am Ort 
der Vielzahl der Zuschauer, wobei die Ubertra- 
gung des Datenstroms bewirkt, daB das be- 
stimmte Video im Empfangsgerat abgespielt 
wird; 

PauseAMederaufnahmemittel zum Empfan- 
gen einer Pauseanforderung und einer nach- 
folgenden Wiederaufnahmeanforderung sei- 
tens eines der Zuschauer; und 

Ersatzmittel, um als Reaktion auf die Wieder- 
aufnahmeanforderung das bestimmte Video 
uber den Vorgriffsstrom anstatt uber den ge- 
meinsamen Datenstrom ubertragen zu kon- 
nen. 
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7. Das System gemaG Anspruch 6, in dem 

ein unterschiedlicher Vorgriffsstrom identifiziert 
wird, nachdem eine Zeitspanne verstrichen ist, 
ohne daft der Zuschauer eine Pausenanforde- 
rung eingeieitet hat. 

8. Das System gemaG Anspruch 6 Oder 7, in dem dem 
Zuschauer ein reservierter Strom zugewiesen wird, 
der wieder freigegeben wird, wenn der Vorgriffs- 
strom identifiziert ist, 

9. Das System gemaG einem der Anspruche 6 bis 8, 
in dem 

das Ersatzmittel das bestimmte Video nicht uber 
den Vorgriffsstrom ubertragt, falls die Wiederauf- 
nahmeanforderung nicht nach einer Zeitspanne 
eingeht, die langer als eine vorgegebene Zeitspan- 
ne seit der Pausenanforderung ist, und das ferner 
enthalt: 

Puff ermittel zum Puffern des gemeinsamen Vi- 
deostroms fur die vorgegebene Zeitspanne als 
Reaktion auf die Pausenanforderung, und 

Pufferzugriffsmittel zum Bedienen des einen 
der Zuschauer aus den Puffermitteln, wenn die 
Wiederaufnahmeanforderung innerhalb der 
vorgegebenen Zeitspanne eingeht. 

10. Ein Verfahren zur Unterstutzung einer Pause-und- 
Wiederaufnahme-Anforderung in einem Video-auf- 
Anforderung-Dienst eines Typs, der eine Vielzahl 
Zuschauer sich gleichzeitig in einen gemeinsamen 
Datenstrom teilen laGt, das aus den folgenden 
Schritten besteht: 

Empfangen einer Vorstellungsanforderung von 
einem der Zuschauer zur Vorfuhrung eines be- 
stimmten Videos; 



meinsamen Datenstroms. 

11. Das Verfahren gemaG Anspruch 10, in dem 

5 das bestimme Video an einem Punkt anlauft, 

an dem der eine der Zuschauer die Pausenan- 
forderung gemacht hat. 

12. Das Verfahren gemaG Anspruch 10 oder 11, das 
10 ferner die folgenden Schritte enthalt: 

Puffern der Videodatenstromeals Reaktion auf 
Pausenanforderungen seitens der Zuschauer, 
wobei die Anzahl der Zuschauer, die von einer 
15 gegebenen Strom kapazitat versorgt werden 

konnen, erhoht wird. 

13. Das Verfahren gemaG einem der Anspruche 10 bis 
12, das die folgenden Schritte enthalt: 

20 

als Reaktion auf die Vorstellungsanforderung 
Identifizieren und Zuweisen eines Vorgriffs- 
stroms, wobei dieser Vorgriffsstrom ein anderer 
Videostrom ist, der so geplant ist, daG er nach 
25 einer vorgegebenen Zeitspanne verfugbar ist; 

und Benutzen des Vorgriffsstroms als alterna- 
tiven Strom. 

14. Das Verfahren gemaG einem der Anspruche 10 bis 
30 13, in dem 

die Alternative ein reservierter Strom ist, der 
aus der Reservekapazitat des Video-Servers 
zugeteilt wird. 

35 

15. Das Verfahren gemaG einem der Anspruche 10 bis 
14, das die folgenden Schritte umfaGt: 

Zuteilen von Pufferraum zum Puffern des ge- 
40 meinsamen Videostroms fur eine vorgegebene 

Zeitspanne, und 

wenn der eine der Zuschauer vor Ablauf der 
vorgegebenen Zeitspanne die Vorstellung wie- 
deraufnimmt, Bedienen dieses einen der Zu- 
schauer mit dem betreffenden Video aus dem 
Pufferraum anstatt uber den alternativen 
Strom. 



gleichzeitiges Senden des gemeinsamen Da- 
tenstroms von einem Video-Server zu den 
Empfangsgeraten an den Orten der Vielzahl 
der Zuschauer, wobei die Ubertragung des Da- 45 
tenstroms bewirkt, daG das bestimmte Video 
auf dem Empfangsgerat der Zuschauer vorge- 
fuhrt wird; 



20 



Eingang einer Pauseanforderung und einer 50 
spateren Wiederaufnahmeanforderung von ei- 
nem der Zuschauer beim Video-Server; und 

1 

als Reaktion auf die Wiederaufnahmeanforde- 
rung das Vorfuhren des betreffenden Videos fur 55 
den einen der Zuschauer durch Beginnen der 
Ubertragung eines alternativen Stroms, der 
das bestimmte Video transportiert statt des ge- 



Revendications 

Procede de support d'une pause-reprise pour un 
systeme video a la demande du type qui peut pren- 
dre en compte des observateurs multiples parta- 
geant un flux de donnees commun, comprenant les 
etapes consistant a : 
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recevoir una demande d'execution de Tun des 
observateurs, pour la presentation d'un pro- 
gramme video particulier, 

en reponse a la demande d'execution, identifier 
et reserver un flux d'anticipation, le flux d'anti- 
cipation etant un autre flux video qui est planifie 
pour devenir disponible apres un intervalle de 
temps predetermine, 

transmettre simuttanement le flux de donnees 
commun depuis un serveur video vers I'equipe- 
ment de reception aux localisations des obser- 
vateurs multiples, la transmission du flux de 
donnees amenant le programme video particu- 
lier a etre execute sur I'equipement de recep- 
tion, 

recevoir au niveau du serveur video, une de- 
mande de pause et une demande de reprise 
ulterieure de I'un des observateurs, et, 
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20 



en reponse a la demande de reprise, transmet- 
tre la video particuliere au moyen du flux d'an- 
ticipation a la place du flux de donnees com- 25 
mun. 

2. Procede selon la revendication 1, dans lequel 

un flux d'anticipation different est identifie apres 30 
qu'un intervalle de temps se soit ecoule sans 
que I'observateur ait lance" une demande de 
pause. 

3. Proc6de" selon la revendication 1 ou 2, dans lequel 35 

en reponse a la demande d'execution, ledit un 
des observateurs se voit affecter un flux reser- 
ve qui est lance lorsque le flux d'anticipation est 
identifie. 40 

4. Procede selon t'une des revendications 1 a 3, dans 
lequel 

ledit un des observateurs se voit allouer un es- 45 
pace tampon suffisant pour mettre en memoire 
tampon le flux video commun pendant un inter- 
valle de temps predetermine. 

5. Procede selon Tune des revendications 1 a 4, com- so 
prenant I'etape supplemental consistant a 



6. Systeme destine au support d'une pause-reprise 
pour un systeme video a la demande du type qui 
peut prendre en compte des observateurs multiples 
partageant un flux de donnees commun, 
comprenant : 

un moyen de reception destine a recevoir une 
demande d'execution depuis I'un des observa- 
teurs pour la presentation d'un programme vi- 
deo particulier, 

un moyen d 1 identification, relie au moyen de re- 
ception et repondant a la reception de la de- 
mande d'execution, destine a identifier et a al- 
louer un flux d'anticipation, le flux d'anticipation 
etant un autre flux video qui est planifie pour 
devenir disponible apres un intervalle de temps 
predetermine, 

un moyen de transmission destine a transmet- 
tre simuttanement le flux de donnees commun 
depuis un serveur video vers un equipement de 
reception au niveau des localisations des ob- 
servateurs multiples, la transmission du flux de 
donnees amenant le programme video particu- 
lier a etre execute sur I'equipement de recep- 
tion, 

un moyen de pause/reprise destine a recevoir 
une demande de pause et une demande de re- 
prise ulterieure depuis I'un des observateurs, 
et, 

un moyen de substitution, destine, en reponse 
a la demande de reprise, a transmettre le pro- 
gramme video particulier au moyen du flux 
d'anticipation a la place du flux de donnees 
commun. 

7. Systeme selon la revendication 6, dans lequel 

un flux d'anticipation different est identifie apres 
qu'un intervalle de temps se soit ecouie sans 
que I'observateur ne lance de demande de 
pause. 

8. Systeme selon la revendication 6 ou 7, dans lequel 

I'observateur se voit affecter un flux reserve qui 
est lance lorsque le flux d'anticipation est iden- 
tifie. 



mettre en memoire tampon des flux de don- 
nees video en reponse a des demandes de 
pause provenant des observateurs, d'ou il re- 
sulte que le nombre des observateurs qui peu- 
vent etre supportes par une capacite de flux 
donnee est augmente. 



9. Systeme selon Tune quelconque des revendica- 
tions 6 a 8, dans lequel 

le moyen de substitution ne transmet pas le pro- 
gramme video particulier en utilisant le flux d'antici- 
pation sauf si la demande de reprise est recue au- 
dela d'un intervalle de temps predetermine depuis 
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la demands de pause, et comprenant en outre : 

un moyen de memoire tampon destined en re- 
ponse a la demande de pause, a mettre en me- 
moire tampon le flux video commun pendant 5 
I'intervalle de temps predetermine, et 

un moyen d'acces en memoire tampon, destine 
a desservir ledit un des observateurs a partir 
du moyen de memoire tampon si la demande 10 
de reprise est recue a I'interieur de I'intervalle 
de temps predetermine. 

10. Precede de support d'une pause-reprise pour un 
service video a la demande d'un type qui permet de is 
prendre en compte des observateurs multiples par- 
tageant un flux de donnees commun, comprenant 
les etapes consistant a : 

recevoir une demande d'execution depuis I'un 20 
des observateurs pour la presentation d'un pro- 
gramme video particulier, 

transmettre simultanement le flux de donnees 
commun depuis un serveur video vers un equi- 25 
pement de reception aux localisations des ob- 
servateurs multiples, la transmission du flux de 
donnees amenant le programme video particu- 
lier a etre execute sur Pequipement de recep- 
tion, 30 

recevoir au niveau du serveur video, une de- 
mande de pause et une demande de reprise 
ulterieure provenant de I'un des observateurs, 

35 

en reponse a la demande de reprise, executer 
le programme video particulier pour ledit un des 
observateurs en debutant la transmission d'un 
flux secondaire transportant le programme vi- 
deo particulier, autre que le flux de donnees 40 
commun. 



1 3. Procede selon I'une quelconque des revendications 
10 a 12, comprenant les Stapes supplementaires 
consistant a : 

en reponse a la demande d'execution, identifier 
et allouer un flux d'anticipation, le flux d'antici- 
pation etant un autre flux video qui est planifie 
pour devenir disponible apres un intervalle de 
temps predetermine, et, utiliser le flux d'antici- 
pation en tant que flux secondaire. 

1 4. Procede selon Tune quelconque des revendications 
10 a 13, dans lequel 

le flux secondaire est un flux reserve alloue a 
partir de la capacity en reserve du serveur vi- 
deo. 

1 5. Procede selon Tune quelconque des revendications 
10 a 14, comprenant les etapes supplementaires 
consistant a : 

affecter un espace tampon pour mettre en me- 
moire tampon le flux video commun pendant un 
intervalle de temps predetermine, et 

lorsque ledit un des observateurs effect ue une 
reprise avant I'intervalle de temps predetermi- 
ne, desservir ledit un des observateurs avec le 
programme video particulier provenant de I'es- 
pace tampon au lieu d'utiliser le flux secondai- 
re. 



11. Procede selon la revendication 10, dans lequel 

le programme video particulier est commence 45 
en un point a partir duquel ledit un des obser- 
vateurs a fait la demande de pause. 

12. Procede selon la revendication 10 ou 11, compre- 
nant I'etape supplemental consistant a : so 

mettre en memoire tampon des flux de don- 
nees video, en reponse a des demandes de 
pause provenant des observateurs, d'ou il re- 
sulte que le nombre des observateurs qui peu- 
vent etre supportes par une capacite de flux 
donnee est augmente. 
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FIG. 6 A 
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FIG. 6B 
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FIG. 7 
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FIG. 10 
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